This invention relates to a method and system for conducting electronic commerce with a remote wallet server.
Electronic commerce over the Internet, and especially the World Wide Web portion of the Internet, is growing at a phenomenal rate. Merchants are taking advantage of the popularity of the World Wide Web by creating online catalogs on web sites, through which consumers can browse and order the merchants' products and services.
In a typical online transaction over the Internet, a consumer will browse a merchant's web site, identify items of interest, and add those items to the consumer's electronic shopping cart. When a consumer is ready to order, the consumer presses an order button, and a merchant sends the consumer a completed order form (typically an HTML-based form) to review and approve. If the consumer desires to complete the order, the consumer fills in the order form with payment and shipping information and returns the form to the merchant.
A disadvantage to the typical process of conducting transactions over the Internet is that the data format used in the merchant HTML-based order forms varies considerably between merchants, and the consumer must therefore re-enter the same payment and shipping information for each merchant at which the consumer shops. Many consumers find the diversity of forms confusing and the process of manually filling in these forms tedious.
In an effort to make online shopping more convenient for consumers, some companies have developed software applications called digital wallets. A digital wallet may store payment and shipping information on a consumer's computer and to use this information to automatically complete a merchant's order form. The digital wallet thus frees the consumer from having to manually re-enter payment and shipping information each time that the consumer makes an online purchase. Digital wallets have been developed as stand-alone applications, as helper applications to browsers, and as browser plug-ins.
Because of the anonymous and open nature of the Internet, electronic commerce over the Internet raises concerns regarding the confidentiality and integrity of transmitted data and the proper authentication of parties involved in a transaction. Various methods of addressing these concerns have been developed and proposed. One such method is the SET™ protocol, which is promulgated and managed by SET Secure Electronic Transaction LLC (www.setco.org). The SET protocol is an open technical standard for the commerce industry developed by MasterCard™ International Inc. and others as a way to facilitate secure payment card transactions over the Internet. SET utilizes cryptography to ensure confidential and secure transmissions of data and digital certificates to create a trust chain throughout the transaction, verifying cardholder and merchant identities. The SET protocol is invoked after a consumer has completed the payment and other information on an order form and is ready to return the order form to the merchant.
Typically, a digital wallet will include application code to perform encryption to ensure the confidentiality and integrity of payment information transmitted during an online transaction. For example, a digital wallet may contain application code to perform the SET protocol. The digital wallet may also include application code for transmitting information according to a standard electronic commerce protocol, such as the Electronic Commerce Modeling Language (ECML). The digital wallet may also include a digital certificate, which may be used to authenticate a consumer. The application code to perform these functions, especially the encryption function, may be lengthy. Therefore, a consumer may find the time to download digital wallet software over the Internet to be inconveniently long.
To shorten the time required for downloading a digital wallet, remote wallet servers have been developed. A remote wallet server is a server that is remote from a consumer's computer and that stores the bulk of the application code for a digital wallet. The remote wallet server may also remotely store the consumer's payment and shipping information. When a remote wallet server is used, a consumer need only store a “thin” client application on his or her computer that communicates with the remote wallet server when the consumer is ready to complete an order with a merchant. The remote wallet server then acts as a proxy for the consumer, sending payment and other purchase-related information to the merchant.
A problem that arises in connection with the use of a remote wallet server is how to authenticate the remote wallet server (which acts as a proxy for the cardholder) to the merchant. Assuming that a digital certificate approach (such as that used by SET) is used between a consumer and a merchant, it has been proposed that the remote wallet server store the consumer's authentication key (i.e., the private key of a cryptographic public key pair used for digital signatures) and the consumer's digital certificate. This approach is problematic because a remote wallet server may provide service to potentially millions of consumers. Therefore, using this approach, the remote wallet server would be required to store potentially millions of authentication keys and digital certificates. This approach is undesirable because it imposes enormous, secure storage requirements on the remote wallet server and because the storage of a large number of consumers' sensitive information (i.e., authentication keys) in one place poses great security concerns.
Another approach that has been proposed is for the remote wallet server to hold a set of its own authentication keys. Each authentication key in the set would be associated with multiple consumers. For example, if a remote wallet server provides service to one million consumers and holds a set of one thousand authentication keys, each authentication key could be associated with a thousand consumers. While this approach would allow the remote wallet server to store many fewer keys than the previous approach, the remote wallet server would still be required to store individual certificates for each consumer (since each certificate would contain individual consumer account information). This approach also has security concerns.
Another approach that has been proposed is for the remote wallet server to store the private key of a recognized certificate signing entity, such as the financial institution that issues a consumer's payment card. The remote wallet server could then generate consumer digital certificates “on the fly” using the certificate signer's private key. While this approach eliminates the need for the remote wallet server to store consumer authentication keys and digital certificates, it raises other concerns. First, since the confidentiality of the private key of the certificate signer (e.g., issuing bank) is of utmost importance to establish trust in a certificate signed by the certificate signer, it is against the certificate signer's interest to share this private key with any other entity. Second, since public key pairs may have expiration dates, the remote wallet server may periodically, in a secure manner, need to be updated with a new version of the certificate signer's private key. Third, generating certificates on the fly could cause increased transaction processing times.
Yet another approach that has been proposed, in the case where a consumer uses an integrated circuit card (also referred to as a “chip card” or “smart card”) as a payment card for an online transaction, is for the remote wallet server to simply pass a cryptogram generated by the consumer chip card to the merchant. The cryptogram will then be forwarded to the financial institution that issued the chip card. Since the chip card shares a secret with the card issuing institution (such as a DES cryptographic key) that it uses to generate the cryptogram, the identity of the chip card holder may be authenticated by the card issuing institution. A disadvantage to this approach, however, is that the cryptogram does not provide any information related to the remote wallet server involved in the transaction. In addition, this approach obviously does not apply to any transactions that do not involve chip cards. Since payment chip cards are not currently widespread, this approach currently does not have wide applicability.
Accordingly, there exists a need for a method and system for authenticating a remote wallet server during an online transaction that substantially improves on the approaches discussed above.